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REPORT  SUMMARY 


Diagnostics  have  been  produced  for  all  Processing  Element 
(PE)  and  Memory  Logic  Unit  (MLU)  printed  circuit  card  types,  including 
several  new  and  revised  types.  Diagnostics  have  "been  generated  for 
approximately  forty  percent  of  those  Control  Unit  (CU)  printed  circuit 
cards  for  which  netlists  have  been  received  from  Burroughs. 

The  Combinational  logic  and  path  tests  were  maintained 
and  work  continued  on  the  control  logic  phase  of  the  off-line  PE 
diagnostics . 

The  software  effort  continues  to  make  good  progress.   Oper- 
ating System  I  (OSl)  is  virtually  complete  and  has  been  run  success- 
fully on  the  Burroughs  B5500.  However,  Burroughs'  failure  to  maintain 
reasonable  progress  in  delivering  a  satisfactory  B65OO  MCP  and  B65OO 
Compatible  ALGOL  may  cause  some  delay  while  the  Operating  System  is 
translated  to  B65OO  Extended  ALGOL.   The  detailed  specification  of 
Operating  System  II  (OSIl)  is  being  resumed. 

GLYPNIR ,  Version  II,  which  allows  better  array  handling  and 
I/O  facilities,  will  be  released  next  quarter.  Work  is  well  under  way 
in  providing  a  COCKROACH  (ILLIAC  IV  FORTRAN)  to  GLYPNIR  translator  for 
educational  and  experimental  purposes.   The  Macro-assembler  is  being 
consolidated  and  properly  documented. 

The  PDP-11  System  for  the  Center  for  Advanced  Computation 
port  to  the  ARPA  net  is  expected  to  be  delivered  during  the  next 
quarter;  much  of  the  software  has  been  designed  and  implemented  using 
a  PDP-11  simulator  on  the  B5500. 

Project  expenditures  and  commitments  through  August,  1970: 

Burroughs  Corporation      $23, 766,781+. 00 
University  of  Illinois       5,659,5^2.92 


Amendment  V  to  the  Burroughs  sub-contract  is  pending  approval, 

The  ILLIAC  IV  Project  Business  Office  now  has  an  accounting 
clerk  who  assists  in  financial  matters  and  related  record  keeping. 
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1.   HARDWARE 

1.1  Diagnostics 

1.1.1  Logic  Simulation 

1.1.1.1  PE  Simulator 

The  PE  Simulator  was  used  principally  for  verification  of 
the  Burroughs  functional  tests.   Some  minor  discrepancies  between  the 
simulator  and  the  actual  PE  were  discovered  and  corrected. 

1.1.1.2  CU  Simulator  System 

Aside  from  changes  to  make  the  generation  of  hoards  more 
trouble-free  and  the  correction  of  an  error  in  the  automatic  naming  of 
files,  the  CU  Card  Simulator  System  has  remained  unchanged. 

The  compiler  for  TESLA  (the  test  language  used  to  generate 
flip-flop  initializations),  however,  has  undergone  various  changes. 
A  new  command  (FFRAND)  has  been  added  to  simulate  the  effect  of  random 
settings  when  the  power  for  a  board  has  been  turned  on.   This  aids  in 
determining  whether  a  series  of  initialization  commands  will  have  the 
proper  effect  in  all  cases.   The  new  TESLA  compiler  also  allows  auto- 
matic file  naming,  zipping  the  appropriate  board  simulator,  and  more 
complete  documentation  of  output.   Since  various  bugs  have  appeared 
with  the  more  frequent  usage  of  TESLA,  a  still  newer  version  is  under 
way  and  should  be  operational  soon. 

Two  programs  (PUNCH /SIGNALS  and  PUNCH /STORAGE)  were  written 
to  create  decks  for  running  TESLA. 

To  facilitate  the  debugging  of  TESLA,  CUTEST/CONTROL,  and 
any  other  programs  which  produce  simulator  input  files,  a  program  to 
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interpret  simulator  input  (SIMIN/PRINTER)  was  written.   It  has  proved 
decidedly  useful. 

Work  on  the  CU  Section  Simulator  continued  this  quarter. 
The  1-0  algorithm  for  partitioning  CU  cards  [l]  was  implemented,  and  a 
system  of  programs  capable  of  generating  input-part  and  output-part 
simulator  bodies  was  completed. 

1.1.2  Card  Test  Generation 

1.1.2.1  Card  Test  Generation  System 

The  major  problem  which  has  been  encountered  in  running  the 
test  generation  system  on  CU  cards  is  the  size  of  the  cards,  which 
causes  long  program  running  times  and  the  creation  of  many  large  disk 
files.   These  effects  cause  some  undesirable  conditions. 

In  order  to  execute  successfully  any  program  which  requires 
more  than  an  hour  of  continuous  processor  time,  it  is  necessary  that 
the  program  be  able  to  recover  from  HALT /LOADS.   This  has  been  done  for 
the  test-failure  cross  reference  program  (CUFAIL/XREF)  and  will  be  done 
for  the  LOCATE  simulator.   A  HALT /LOAD  proof  program  to  print  cross 
reference  dictionaries,  which  may  be  up  to  3000  pages  in  length,  has 
been  written  (CUFAIL/PRINTER) .   Also,  to  enable  programs  which  have 
been  zipped  but  have  not  yet  completed  execution  to  restart  execution 
after  a  HALT  /LOAD,  all  the  programs  on  the  system  are  being  modified 
so  that  any  program  may  have  a  data  deck. 

Large  disk  files  cause  situations  in  which  no  additional 
disk  space  is  available  to  users,  making  further  processing  impossible. 
Because  many  of  the  files  simply  need  to  be  large,  this  is  a  difficult 
problem  to  solve  completely.   Disk  allocations  on  any  output  files  that 
were  found  to  be  over-allocated  have  been  cut  down.   The  most  helpful 
solution,  to  date,  has  been  to  load  from  the  board  tape  only  those  files 
which  are  needed  for  the  programs  to  be  run.   To  facilitate  this,  an 
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automatic  loading  program  (LOADME/WWOFK)  has  been  written  which  decides 
from  the  contents  of  the  tape  which  files  are  to  he  loaded. 

Numerous  large  files  have  also  caused  severe  cramps  in  our 
supply  of  backup  storage  medium  (magnetic  tapes).   Various  solutions 
have  been  attempted  with  a  certain  amount  of  success.   Since  library 
tapes  are  likely  to  be  only  partially  used  at  best  (particularly  for 
some  of  the  smaller  boards)  some  of  the  large  files,  which  previously 
had  their  own  tapes ,  have  been  converted  to  library  files  and  stored 
on  the  library  tapes.   Two  utility  programs  (CUFAIL/COPY  and 
LOCATE/COPY)  have  been  written  to  accomplish  the  storage  conversion. 
At  present,  nearly  all  tapes  are  over  70%   utilized.   The  efficient 
utilization  of  tapes  has  the  disadvantage  of  considerably  increasing 
the  amount  of  time  to  load  or  dump  files  to  the  tapes .   Some  thought 
is  presently  being  expended  on  ways  of  automatically  removing  outdated 
files . 

Since  there  may  be  as  many  as  200  to  300  disk  files  involved 
in  each  board  by  the  time  test  generation  is  completed,  organizational 
problems  can  result.   A  program  to  print  compact  and  alphabetized  tape 
directory  listings  (TAPEDIR/WWOFK)  has  proved  valuable  in  counteracting 
this  problem. 

1.1.2.2  Card  Test  Translation  System 

Using  the  experience  gained  from  earlier  versions ,  the  final 
version  of  the  CU  Card  Test  Translation  System  was  implemented  and 
debugged  early  in  the  quarter.   The  new  version  emphasizes  economical 
usage  of  both  real  and  process  time  during  its  operation.   The  new, 
extensively  revised,  XALGOL  version  of  the  PEX  compiler  proved  itself 
far  faster  and  more  efficient  than  its  predecessor.  The  PEXTAP  trans- 
lators for  both  the  main-programs  and  initializations  were  revised 
to  produce  in-line  code,  eliminating  hundreds  of  slow  procedure  calls 
and  making  full  use  of  the  eight  microsequence  memory  registers  in 
the  exerciser.   Consequently,  both  translation  and  compilation  are 
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30%  faster,  with  an  average  process-to-real  time  ratio  of  6:10.   The 
INIT  program  can  be  executed  from  a  teletype  which  speeds  creation  of 
initialization  code;  for  example,  50  INITs  in  15  minutes. 

Wrap-around  test  procedures  in  the  form  of  two  pseudo-boards, 
TEST1  and  TEST2,  were  created  to  test  the  reliability  of  the  CU  Card 
Tester.   This  was  accomplished  by  writing  two  netlists  in  which  all  pins 
were  used  (half  as  input  and  half  as  output),  with  each  input  logically 
connected  to  an  output  pin.   Any  discrepancies  in  testing  will  reflect 
malfunctions  and/or  errors  in  the  yet  virgin  CU  Card  Tester  Exerciser. 

1.1.2.3  PE  Card  Test  Generation 

Seventeen  new  or  revised  PE  card  logic  prints  were  received 
at  the  beginning  of  the  quarter.   Tests  for  these  were  quickly  generated 
and  forwarded  to  Burroughs . 

During  the  last  week  of  the  quarter  thirteen  more  PE  card 
revisions  were  received.   Tests  for  these  will  be  generated  during 
the  first  few  days  of  the  new  quarter.   In  addition,  an  invalid  test 
sequence  was  generated  for  the  Al6  card  and  must  be  corrected. 

1.1.2.1+  CU  Card  Test  Generation 

Due  to  personnel  changeover,  vacations,  and  machine  down-time, 
test  generation  fell  considerably  behind  projections  this  quarter. 
Nevertheless,  the  following  processing  has  taken  place  on  the  sixty-six 
board  types  whose  netlists  have  been  received  from  Burroughs: 

Board  Simulators  Generated  60 

Failure  Detection  Complete  31 

Test  Tapes  Generated  27 

Dictionaries  Generated  30 

Test  Tapes  Sent  to  Burroughs  26 

Dictionaries  Sent  to  Burroughs  23 
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The   continuing  lack  of  feed-back,    due  to  the  non- functioning 
of  the  Burroughs   CU  Card  Tester   for  the  entire  past  quarter,    is 
disheartening. 

1.1.3     PE  Diagnostics 

1.1.3.1  Path  Tests 

In  this  quarter  the  path  tests  were  maintained.  The  updated 
path  tests  have  "been  sent  to  Burroughs. 

1.1.3.2  Combinational  Tests 

The  combinational  tests  were  completed  during  this  quarter. 
The  test  sequences  have  been  sent  to  Burroughs. 

1.1.3.3  Control  Logic  Tests 

The  control  logic  test  is  divided  into  three  main  tasks: 
equation  generation,  test  pattern  generation  for  the  logic  being  tested, 
and  test  sequence  generation  with  respect  to  the  PEX  and  PE. 


Updating  of  the  equations  is  90%  complete.  The  completion  of 
this  first  task  requires  the  latest  version  of  the  PE  backplane  netlist 
which  has  not  been  received  from  Burroughs. 

The  second  task  is  complete.   The  algorithm  used  for  test 
generation  is  new  and  unique.   The  completeness  of  its  fault  location 
capability  was  reviewed  and  the  study  revealed  some  flaws  in  the 
algorithm.   A  new  one  has,  therefore,  been  derived. 

A  file  editing  program  has  been  written  for  obtaining  the 
control  logic  test  sequences  in  PE  exerciser  assembly  language.   Ini- 
tializations for  the  tests,  test  data  inputs,  and  expected  responses 
are  generated  manually.   Progress  was  impaired  by  a  lack  of  knowledge 
of  the  design  details  of  the  PE,  unavailability  of  the  latest  back- 
plane netlist,  and  inconsistencies  between  logic  diagrams  and  wire 
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lists.   Greater  progress  is  expected  in  the  future  following  a  better 
acquaintance  with  the  PE  design. 

1.1.3.1*  Functional  Tests 

Verification  of  all  but  a  couple  of  the  Burroughs  functional 

tests  has  been  completed  using  the  PE  Simulator.  Almost  all  functional 

tests  were  found  to  be  correct.   Those  containing  errors  were  reported 
to  Burroughs . 
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2 .   SOFTWARE 


2.1  Operating  System 

2.1.1  Operating  System  I 

All  modules  (see  following  page)  of  the  operating  system 
except  the  Job  Partner,  Hardware  Supervisor,  and  OSU  (that  part  of  the 
operating  system  which  resides  in  the  ILLIAC  IV)  are  coded,  debugged, 
integrated,  and  running  as  a  unity  on  the  B5500.   A  Simulated  Hardware 
Supervisor  is  being  provided  for  the  B5500  integration  which  will  allow 
the  completion  of  the  Job  Partner,  and  the  running  of  OS^  (under  the 
ILLIAC  IV  simulator)  with  this  integrated  system.   OS^  has  been  held  up 
because  of  the  recent  discovery  of  undocumented  changes  in  the  interrupt 
system,  which  necessitated  its  rewriting.   The  Hardware  Supervisor  is 
being  delayed  by  the  poor  reliability  of  the  B65OO  and  its  software. 
These  delays,  in  turn,  prevent  the  completion  of  the  Job  Partner,  in 
the  light  of  Burroughs'  statements  that  Compatible  ALGOL  will  have  the 
lowest  priority  as  far  as  completion  and  maintenance  is  concerned; 
further  delays  will  be  necessitated  while  the  entire  operating  system 
is  translated  from  Compatible  to  Extended  ALGOL.   Despite  these  delays, 
the  entire  operating  system  should  be  integrated  and  working  with  the 
ILLIAC  IV  simulator  by  the  end  of  November. 

Work  is  proceeding  with  the  following  enhancements  to  the 
operating  system: 

•  enhanced  communication  over  the  48-bit  path 
between  the  B65OO  and  ILLIAC  IV  which  will 
allow  more  diverse  control  of  the  system 
by  ILLIAC  IV; 
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"Job  Information  Flow 
•System  Information  Flow 


Operating  System  I :  Module  Configuration 
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•  adding  timing  and  other  instrumentation  to  the 

operating  system  (there  was  none  in  the 
original  design),  to  help  with  its  tuning 
in  simulation  or  with  the  real  ILLIAC  IV; 

•  augmented  version  of  break  facilities  to  help 

with  debugging  and  scheduling; 

•  an  investigation  of  scheduling  algorithms  to 

ILLIAC  IV,  including  a  timing  simulation 
of  ILLIAC  IV; 

•  disk  map  checking  facilities  in  the  ILLIAC 

Control  Language,  to  insure  that  the  disk 
mapping  requested  by  the  user  is  realizable 
and  to  inform  him  if  it  is  not  so  before 
his  job  execution  is  commenced. 

User,  System,  and  Maintenance  documentation  is  being  prepared. 
2.2  Compilers  and  Translators 

2.2.1  GLYPNIR 

Version  II  of  GLYPNIR  will  be  released  very  shortly.   The 
major  enhancements  (compared  to  Version  I)  are: 

•  I/O  statements  for: 

a)  semi- format ted  I/O  statements  for  use  with 
the  ILLIAC  IV  Simulator, 

b)  block  oriented,  unbuffered  disk  I/O; 

•  vectors  as  a  data  type  (previously,  vectors  had 

to  be  accessed  with  pointers); 

•  improved  interface  with  assembly  language, 

allowing  easier  embedding  of  Macro-assembler 
code  within  GLYPNIR  code; 
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•    more   extensive  standard  mathematical  routines    and 

intrinsics    for  routing,   rotating,   and  shifting. 

2.3     Macro- Assembler 

The  Macro- assembler,    as    it   stands,    evolved  from  the  assembler, 
and,    as    a  consequence,   its  workings    are  rather  fortuitous.      Thus,    despite 
the   fact  that  most  users   are   finding  it  satisfactory,   some  bugs   occurring 
in  the   "evolutionary"  part   of  the  Macro- assembler  are  becoming  very 
difficult  to   find  and  correct.      This  part   of  the  Macro-assembler  is  thus 
being  re-designed  and  rewritten.      The   re-write  should  be   finished  by  the 
end  of  October.      It  will  not   affect  running  programs. 

An  effort  to   collect   and  compile  a  unified,    coherent  Macro- 
assembler Manual   from  the  scattered  literature,   now  available,    continues. 

2.  k     Interactive   Communications    and  Graphics 

When  it  became   apparent  that  the  ILLIAC   IV  might  not  be 
located  on  the  Urbana  Campus    of  the  University   of  Illinois ,   steps  were 
taken  to   ensure  that  both  the  University   of  Illinois   and  Burroughs 
(Paoli)   were  linked  to  the  AEPA  Net.      This   involves   interfacing  an  IMP 
to  the  B6500  at  Paoli    and  an  IMP  to   a  PDP-11   at  Urbana.      Limited 
graphics    facilities  will  be  interfaced  to  the  PDP-11;   but  the  main 
function  of  the  PDP-11   is   to  handle  ARPA  Net   and  user  protocol   for  the 
Center.      In  order  to  make  the  best  of  the  limited  time   available,    a 
PDP-11   simulator,    assembler,    and  a  higher  level  language  with  which  to 
program  the  operating  system  were   started.      It   is   anticipated  that  the 
PDP-11  will  be   delivered  by  the   end  of  1970   and  that  the  link  to  Paoli 
will  be   operational  by  April   1971. 

•  Hardware  Status 

•  the  basic   system  design   around  the  PDP-11  has 

been   completed; 

•  the  PDP-11  System  bid  is   in  progress;   the  system 

is   expected  to  be  ordered  on  October  15 >   1970; 
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a  graphics  terminal  has  been  ordered; 

a  PDP-11  to  IMP  interface  has  been  designed, 
checked, and  is  under  construction; 

the  B65OO  to  IMP  interface  proposal  was 
returned  to  Paoli  on  August  18,  1970 
for  reconsideration  by  Burroughs; 

hardware  configuration  checked  at  Digital 
Equipment  Corporation  August  31,  1970. 


•  Software  Status 

•  preliminary  investigations  are  under  way 

into  B65OO  MCP  code  changes  for  data- 
communications  ; 

•  PDP-11  System,  Version  I,  is  50%  coded; 

•  a  PDP-11  assembler  on  the  B5500  is  working 

and  is  being  extended; 

•  a  PDP-11  simulator  on  the  B5500  is  being 

coded  and  debugged; 

•  a  single  contour  line  generation  routine  for 

ILLIAC  IV  is  being  completed  and  checked; 

•  a  surface  presentation  routine  for  ILLIAC  IV 

is  coded; 

•  a  Calcomp  type  plot  system  for  the  terminal 

is  being  designed. 

2. 5  Debugging  Package 

Work  on  the  debugging  package  has  progressed  to  the  stage 
where  a  simple  version  will  shortly  be  made  available  with  the  ILLIAC  IV 
simulator  on  the  B5500.   Further  information  is  presented  in  FOURUM 
Communication  No.  26. 
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2.6  B5 500  Operation 


No.  of    Process 
Jobs      Hours 


July  25,989    I8O.85 

August  19.330    208.62 

A  few  days  were  lost  during  the  quarter  due  to  air-conditioning 
problems;  these  are  now  solved.   There  has  been  a  hardware  problem  with 
the  memory  mod  files;  although  it  has  been  fixed,  memory  checks  still 
occasionally  appear--a  HALT/LOAD  usually  restores  the  machine. 

Throughput  has  been  good  and  response  time  has  been  fine.   The 
present  status  of  the  MCP  is  Mark  X,  IiEVEL  36. k3. 
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3-   APPLICATIONS 


3.1  Numerical  Analysis 

3.1.1  Matrix  Inversion  and  Solution  of  Linear  Algebraic  Equations 

This  quarter,  the  method  of  Householder  triangularization  as 
described  in  the  last  QPR  [2]  was  coded  in  ASK  and  executed  on  the  SSK 
simulator.   This  program,  which  consists  of  several  routines,  inverts 
a  matrix  or  solves  a  matrix  equation,  AX  =  B,  where  A,  B,  and  X  are 
matrices. 

The  task  at  hand  is  to  provide  an  iterative  improvement 
scheme  using  the  results  of  the  above  program.   Two  routines  are  coded 
in  ASK:   one  for  improvement  of  the  solution  of  the  matrix  equation, 
and  another  for  improving  the  inverse  of  a  matrix.   The  former  routine 
is  in  a  check-out  phase  on  the  simulator,  and  the  latter  routine,  the 
improvement  for  the  inverse  of  a  matrix,  is  executing  correctly  on  the 
simulator. 


The  procedure  for  the  improvement  of  the  solution  is  as 
If  X„  is  the  result  obtained  from  Hous< 
tion,  the  residual  vector  or  matrix  is  obtained, 


follows:   If  Xn  is  the  result  obtained  from  Householder  triangular  iza- 


R  =  B  -  AX 
m        m 


The  correction  matrix,  S   ,  can  be  found  by  solving  the  equation 

'   xm  J  D 


AS   =  R 
xm    m 

Provided  that  double  precision  arithmetic  is  not  used  and  that  the 
upper  triangle  and  other  requisite  vectors  are  saved  from  the  original 
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reduction,  S   is  readily  obtained  "by  back-substitution.   The  improved 
solution  becomes : 


X  ,.  =  X  +  s 

m-KL    m    xm 

The  improvement  of  the  inverse  involves  a  similar  procedure-- 
without  the  necessity  of  solving  a  matrix  equation  at  each  iteration. 
If  Xn  is  the  result  of  Householder  triangularization,  find 

DQ  =  I  -  AXQ    . 

Obtaining  D  ,  the  improved  inverse  may  be  derived  as: 

X  =  X  _  (I  +  D  -)    , 
m    m-1  v     m-1' 

where  D  =  D~  . 
m    0 

3.1.2  Eigenvalue  Problems 

3.1.2.1  Jacobi ' s  Algorithm 

Jacobi's  algorithm  for  finding  eigenvalues  of  symmetric  matrices 
has  been  written  and  debugged  and  is  in  the  stage  of  being  tested  for 
different-size  matrices.   A  document  describing  the  algorithm  and  the 
features  of  the  program,  written  in  ASK,    is  being  written. 

3.1.2.2  Eberlein's  Algorithm 

A  Jacobi-like  algorithm  for  real  non-symmetric  matrices  is 
under  investigation.   A  short  description  of  the  algorithm  [3]  may  be 
presented  as:   "A  matrix,  A,  is  normalized  by  undergoing  a  sequence  of 


orthogonal  transformations.   Once  the  matrix  is  normalized  (i.e.,  the 

T    T 

matrix  C  =  (A  •  A  -  A  A)  is  arbitrarily  small)  one  is  able  to  reduce 

the  matrix  to  a  diagonal  form  and,  thus,  obtain  the  eigenvalues  of  A." 
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The  orthogonal  transformation  matrices  are  of  the  form: 


(1) 


Mi=' 


C 


lu 


W 


(u,  v)  different  from  (2k-l,  2k)  ¥k 
otherwise 


This  transformation  is  used  to  speed  up  the  rate  of  convergence. 

(u,v)  is  found  "by  searching  for  max|c.  .  |(i  ^  j).   The  trans- 
formation  "brings  the  element,  c.  . ,  thus  found,  into  the  position 
(2k-l,  2k),  where  it  will  have  the  most  appreciable  effect  on  the 
convergence  of  the  algorithm. 


(2) 


f£  -  diag   ux      >    12      ,    '•->    ln/2 


with  T,    = 

k 


:d 


cos  cd, —  sin  cp,v 

k  ^k 


(i) 

k 


•sin  qV_  cos  qv 


U) 

k 

U) 


co,     is   determined  by  tan  2cp 


U) 


.(i)     _  c(i) 

"2k-l,2k-l    2k, 2k 


2c 


2k- 1,2k 


The  orthogonal  matrix,  P,  is  chosen  such  that  the  off -diagonal  elements, 
c       ,  for  all  k  attain  their  maximum  positive  value. 


(3) 


-  dlag  (a<'>,  SW,  ....  s«>) 


with 


bl   "  b2 


V2 


cosh  \|r-     sinh  iK 
sinh  iK     cosh  \K 
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\Jr.  is  derived  from: 


where 


vith 


tanh  k  if.    =  -2k2(A«)  k^A*)    , 


AWVP  WP    "' 


.2    „2 


k0  =  £  D.   E.   and  kn  =  E  (D.   +-  E.  ) 
2        km  km      1       v  km    km 
k,m  k,m 

Dkm  =  (a2k-l,2m-l  '  a2k,2m^  and  Ekm  =  (a2k-l,2m 


-  a 


2k 


,2m-l^ 


Where  (l),  (2)  and  (3)  are  applied  to  A*  -,  ,  i.e., 

Vi  ■  ^W1  WiiV    « 

AW(Aj  -  0  as   I  -  oo,   hence  IT(C-)  -  0 


A,,   is    arbitrarily   close  to  being  normal. 

The   following  tests  were  undertaken  in  an  attempt  to   find 
when  A  is    close  to  being  normal   for  a  finite  I. 

2 
Tests   showed  that  when  plotting  AN   (A)    against   &,   the  rate 

2  -10 

of   convergence  levels    off  at  AW   (A)    =  0(10   "   )    rather  quickly,  but  the 

matrix,   A,    does   not   show  satisfactory  normalization. 


AN2(A) 


o(iof3) 


o(io-10)  - 


rate  of 
-x  convergence 


critical  point 


->    I 
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Tests  also  showed  that  at  .^l'(A)  =  0(10  "  )  the  elements  of 

c  and,  especially,  max|c..|  begin  to  oscillate  as  soon  as  they  reach 

-5 
the  order  of  €  =  10   .   This  oscillation  is  critically  reflected  in 

the  transformation  matrix,  P,  which  is  close  to  the  identity-matrix  at 

that  point  and,  therefore,  does  not  contribute  significant  changes  in 

A  toward  normalization. 

A  suggestion  which  might  solve  the  problem  is  to  check 

F  =  lc2k_i  2k- 1  "  °2k  2k  I  -  10"  '  where  b  ranges  from  1-3- 

If  this  test  is  satisfied,  then  cp^.  should  not  be  determined 
by  using  F  i-   0,  but  rather  by  using  the  cp^  for  F  =  0  [3].   Investiga- 
tion for  determining  a  most  general  b  and  its  effect  on  the  matrix 
under  consideration  is  under  way — early  indications  show  promising 
results . 


3.1.2.3  QR-Algorithm 

The  ASK  program  for  finding  eigenvalues  of  up  to  Gh   x  6U 
real  Hessenberg  matrices  using  the  QR-algorithm  [k]   has  been  written. 
The  program  is  currently  in  the  final  stage  of  being  debugged  on  the 
SSK  simulator;  it  is  expected  to  be  complete  by  the  end  of  October. 

3.2  Linear  Programming 


Assembly  and  simulation  of  segments  of  the  Linear  Programming 
System  (LPS)  code  continues  as  a  major  task  of  the  linear  programming 
group.   The  LP  project  has  been  allocated  one  hour  each  day  of  priority 
use  of  the  B5500  computer  for  this  purpose.   During  this  time  an  average 
of  approximately  2  ASK  compilations  and  2  SSK  simulated  executions  can 
be  run.   The  inclusion  of  macro  instructions  in  the  ASK  code  stream 
significantly  increases  the  compile  time  over  that  of  non-macro  codes. 
Most  of  the  LP  codes  now  contain  the  macro  1/0  instructions  discussed 
in  the  previous  QPR ,  and  thus  computer  throughput  has  been  reduced. 
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Software  efforts  of  the  LP  group  have  included  debugging  the 
LP  I/O  macros  and  developing  subroutine  linkage  conventions  for  ASK 
applications  programs.   User  documentation  for  the  I/O  macros  has  been 
provided. 

Code  development  for  the  LP  matrix  reinversion  routine, 
INVERT,  was  begun  this  quarter.   A  modular  system  flowchart  was  drawn 
up  for  the  inversion  procedure  discussed  in  "An  Error  Analysis  of 
Solutions  to  Sparse  Linear  Programming  Problems"  by  R.  Jonathan  Lermit 
[5]-   Many  modifications  had  to  be  made  in  the  implementation  design  of 
this  algorithm.   Detailed  flowcharts  and  ILLIAC  IV  assembly  code  were 
produced  for  the  initial  data  processing  modules  of  the  INVERT  routine. 

At  a  recent  meeting,  the  7th  Mathematical  Programming  Symposium 
held  in  the  Netherlands,  E.  Hellerman  and  D.  Ranck  presented  a  paper 
entitled,  "Reinversion  with  the  Preassigned  Pivot  Procedure",  outlining 
an  LP  inversion  technique  which  produces  an  improved  inverse.   It  is 
claimed  that  implementation  of  this  scheme  for  the  CDC  and  IBM  LP  systems 
performs  reinversion  six  to  ten  times  faster  than  the  previous  procedure 
and  substantially  reduces  the  number  of  non-zeros  in  the  inverse  matrix 
file.   In  discussions  with  one  of  the  authors,  it  was  determined  that 
this  scheme  is  suitable  for  the  ILLIAC  IV  LP  system.   The  code  already 
produced  for  the  previous  INVERT  design  is  still  applicable;  new  system 
module  flowcharts  will  be  developed  during  the  next  quarter. 

3.3  Long  Codes 

Following  an  extensive  revision  to  provide  better  documenta- 
tion, the  system  identification  programs  were  used  to  study  the  ability 
of  the  identification  algorithms  to  estimate  the  parameters  of  linear 
dynamic  systems  under  a  variety  of  conditions.   In  order  to  study  the 
effects  of  varying  levels  of  noise  contamination,  the  variance  of  the 
essentially  Gaussian  noise  vectors  added  to  the  system  state  vectors 
(plant  noise)  and  the  variance  of  the  noise  vectors  added  to  the 
observation  vectors  (observation  noise)  were  independently  varied  by 
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scaling  the  noise  vectors  used.   The  observed  vector  for  a  given  time 
step  should  be  affected  by  the  observation  noise  vector  occurring  at 
the  current  time  step  only,  while  plant  noise  vectors  from  previous 
time  steps  should  affect  the  observation  through  the  transition  matrix. 
Since  it  is  desirable  to  have  the  noise  terms  for  a  given  time  step 
uncorrelated  with  the  noise  from  previous  time  steps,  plant  noise  was 
expected  to  have  a  more  detrimental  effect  on  the  accuracy  of  the 
identification  process  than  observation  noise.   The  experiments  con- 
ducted, however,  showed  the  reverse  is  often  true.   To  cope  with  this, 
a  new  algorithm  specifically  designed  to  minimize  observation  noise 
contamination  has  been  developed  and  is  being  implemented.   Studies 
were  also  begun  to  determine  the  ability  of  the  identification  algo- 
rithms to  identify  systems  formed  by  subjecting  transformation  matrices 
in  the  more  desirable  companion  matrix  form  to  arbitrary  non-singular 
similarity  transformations. 

3. k     Large  Scale  Planning 

Much  of  the  work  in  this  area  during  the  past  quarter  has  been 
concentrated  on  the  geometric  matrix  generator  mentioned  in  the  last  QPR 
[2].   The  rationale  for  this  generator,  its  preliminary  specification, 
and  a  brief  discussion  of  a  proposed  report  generator  follow. 

3.^.1  Matrix  Generator 

Since   linear  programming  matrices    are  typically  very   sparse 
and  contain  repetitive,    dense  sub-arrays   of  non-zero   coefficients,   they 
lend  themselves   to   formulation  by  the  use  of  matrix-generation  codes. 
There   are  several  possible   approaches   to  the  problem  of  matrix  genera- 
tion,   including  model-specific   generators,    generators  based  on  algebraic 
functions   relating  variables,    and  generation  languages.      The  approach 
to  be  used  here  is   that   of  language.      Since  the  number  of  geometric 
structures  which   occur  as   sub-arrays  within  a  linear  programming  matrix 
is    small,    the  generator  language   is    designed  to  allow  the  user  to  define 
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sub-arrays   in  geometric   terms,    and  build  a  matrix  for  a  specific  problem 
by  providing  dimensions    and   coefficients    for  these  sub-arrays. 

The   structures    occurring  in  linear  programming  matrices   are: 

(i)  point; 

(  i  i )  row ; 

(iii)  column; 

(iv)  square; 

(v)  rectangle; 

( vi )  parallelogram ; 

(vii)  diagonal; 

(viii)  band; 

(ix)  lower  band; 

(x)  upper  band; 

(xi)  lower  triangle;    and 

(xii)  upper  triangle. 

Structures    (vi)    through    (xii)   have   left   and  right  mirror  images,  which 
are  themselves    structures.      Also,    a  band  matrix  is    an   extension  of  a 
diagonal   and  can  be   represented  as    5-di agonal,    3-di agonal,    etc.      "Upper 
band"   and   "lower  band"   are   structures   in  which   exists   the  main  diagonal 
with   one   or  more  secondary   diagonal(s)    above  or  below  it. 

Since  these  structures,   in   combination,    form  the  structure  of 
a  sparse  matrix,    their  existence   can  be   exploited  to   form  a  linear 
programming  matrix.      This   is   the  philosophy   of  the  matrix  generator. 

In   order  to  use  this   principle  to   create   a  matrix,   it  is 

necessary  to   define  the  structure  required  for  a  sub-array,    its  location 

in  the  matrix,    its    dimensions,    the   coefficients   to  be   inserted,  and  the 
number  of  times   the  structure   is   repeated  across   the  matrix. 

Sub-array   location  in  the  matrix  is   defined  by   an   (x,y) 
coordinate  system,  with    (0,0)    at   the  northwest   corner  of  the  matrix. 
This    coordinate  system  is    also  used  to   identify  the  blocks   of  columns 
and  rows   to  which  the  specific   real-world  activities    and  constraints 


■  22- 


relate.   (User-generated  real  names  can  be  input  and  passed  to  the 
report  generator  for  solution  interpretation.) 


The  characteristics  of  the  structure  definitions  are: 


(i) 


POINT 

Size 

Value 

Repeat  Factor 


none  given 
only  one  number 

single  element  repeated  horizontally  by 
number  given  as  repeat  factor 


(ii)   ROW 


Size         -  one  number  gives  number  of  columns  spanned 
Value         -  values  given  are  accepted,  one  per  column. 

If  the  number  of  values  is  less  than  the 
given  size,  the  last  value  is  repeated 
for  the  remaining  columns . 
Repeat  Factor  -  row  structure  defined  is  repeated 

specified  number  of  times 


mutatis  mutandis 


one  number  taken  as  the  number  of  rows 
and  columns 

only  one  number  given,  which  is  assigned 
to  all  S  elements 

horizontal  repetition  of  the  S  sub- 
structure 


two  numbers  are  accepted,  with  c 

referring  to  columns  and  r  to  rows 
one  number  is  assigned  to  all  cr  elements 
horizontal  repetition  of  cr-element 
substructure 


(iii) 

COLUMN 

Same  as  ROW,  : 

(iv) 

SQUARE 

Size 

Value 

Repeat  Factor 

(v) 

RECTANGLE 

Size 

Value 

Repeat  Factor 

(vi)   PARALLELOGRAM  [Left  and  Right] 


Size 


Value 


(vii) 


-  two  numbers,  the  first  refers  to  number  of 
elements  in  each  diagonal  and  the  second 
to  the  number  of  diagonals 

-  number  of  values  equal  to  the  number  of 

diagonals  accepted,  the  first  referring 
to  the  uppermost  and  the  others  to 
lower  diagonals,  in  order 
Repeat  Factor  -  horizontal  repetition 

DIAGONAL  [Left  and  Right] 

Same  as  ROW,  mut at i s  mu t andi s 
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(viii)   BAND  [Left  and  Right] 

Size         -  two  numbers  accepted;  the  numbers  of 

diagonals,  b,  and  the  number  of  elements 
on  the  main  diagonal,  d.   The  number  of 
elements  on  adjacent  subdiagonals  is 
d  -  1. 

Vaj-ue         -  as  for  PARALLELOGRAM 

Repeat  Factor  -  matrix  of  size  d  x  d  with  banded  structure 

is  repeated  horizontally 

(ix)   LOBAND  [Left  and  Right] 
Same  as  BAND 

(x)   HIBAND  [Left  and  Right] 
Same  as  BAND 

(xi)   LOTRI  [Left  and  Right] 

Size  -  one  number,  d,  is  taken  as  the  size  of  a 

square  submatrix 

Value         -  each  number  given  is  used  as  the  value 

for  all  elements  of  one  lower  triangular 
matrix.   A  sequence  of  numbers  will 
define  an  equal  number  of  lower  trian- 
gular matrices,  with  entries  equal  to 
the  numbers  in  the  sequence. 

Repeat  Factor  -  the  sequence  of  lower  triangular  matrices 

defined  by  the  given  values  are  repeated 
hori  zontally 

(xii)   HITRI  [Left  and  Right] 
Same  as  LOTRI 

The  matrix  generator  will  permit  the  user  to  structure  his  model 
using  declarations  giving  the  starting  coordinates,  the  sub-structure, 
its  dimensions,  the  value(s)  to  be  inserted,  and  the  repeat  factor.   For 
example,  the  statement 


50 , 100 ; LOTRI ( 50 ) : 1 . 0*10 

causes  the  generation  of  a  50  by  50  left-lower  triangular  matrix  of 
values  1.0,  starting  at  row  50  and  column  100,  and  repeated  10  times 
horizontally.   This  one  statement  thus  generates  12,750  matrix  coeffi- 
cients which  would  have  been  entered,  using  conventional  means,  as 
12,750  entries  <R0W  NO.  COLUMN  NO.  VALUEX   Similarly,  the  statement 
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UOO ,1000 ;COL( 12) : LAB0RA*50 

will  create  50  contiguous  columns  of  12  values  drawn  from  a  file  named 
LABORA,  starting  at  row  1+00  and  column  1000.   The  conventional  procedures 
would  have  required  600  card  entries  to  input  these  data. 

3.^.2  Report  Generator 

A  major  source  of  the  costs  of  using  linear  programming  is 
that  of  interpretation  of  solutions.   In  the  conventional  use  of  linear 
programming  the  solution  output,  consisting  of  lists  of  basis  vectors 
and  details  concerning  them,  must  be  manually  interpreted.   When  the 
model  is  of  the  magnitude  of  a  sectoral  model,  the  task  of  interpreting 
the  solution  is  formidable  and  costly.   The  objective  of  a  report 
generation  system  is  to  facilitate  the  output  of  interpretive  reports 
of  the  solution  to  a  linear  programming  problem. 

The  report  generator  to  be  developed  here  is  closely  related 
to  the  matrix  generator  discussed  above.   The  real-world  names  of 
activities  and  constraints  will  be  defined  by  the  user  as  input  to  the 
matrix  generator.   The  sets  of  columns  and  rows  spanned  by  these  names 
will  be  given  dimensions  in  terms  of  the  (x,y)  coordinate  system  used 
by  the  matrix  generator.   This  will  enable  the  report  generator  to  match 
the  real-world  names  with  the  column  and  row  names  internally  assigned 
by  the  linear  programming  code.   Report  formats  will  be  variable  and 
will  allow  some  user-defined  variations  dependent  on  the  requirements 
of  the  decision  makers  receiving  the  output.   This  will  be  accomplished 
by  allowing  the  user  to  specify  the  sets  of  linear  programming  output 
to  be  passed  through  the  report  generator.   For  example,  if  the  user 
desires  the  marginal  products  of  certain  limiting  resources,  he  will 
be  able  to  specify  these  by  an  input  declaration  which  will  cause  the 
linear  programming  "reduced  costs"  to  be  output  in  the  report. 

3.^.3  Sector  Model 

The  generalized  sector  model  is  also  in  the  definitional  phase. 
The  philosophy  being  followed  is  that  of  generic  activity  and  constraint 
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sets  which  can  be  reproduced  by  the  matrix  generator  under  parameter 
control.   The  next  report  will  discuss  the  model  philosophy  in  more 
detail. 

3. 5  Signal  Processing 

The  matrix  convolution  program  is  being  extended  to  handle 
matrices  with  column  dimensions  in  excess  of  6k.      It  is  anticipated  that 
this  effort  will  be  completed  and  documented  in  the  first  half  of  the 
fourth  quarter.   The  program,  written  in  ASK,  currently  is  operational 
for  the  convolution  of  two  matrices  whose  resulting  matrix  has  6h   columns 
or  less. 

A  preprocessor  program  to  read  9-track  input  tapes  and  set  up 
tables  and  file  allocations  for  all  line,  shot,  velocity  and  normal  move- 
out  information  is  approximately  25%  complete.   This  program  is  being 
written  for  the  B65OO  computer  to  organize  the  data  for  operations  in  the 
ILLIAC  IV,  utilizing  ILLIAC  IV  as :   l)  a  group  of  6h   serial  computers; 
2)  a  group  of  128  serial  computers  using  32  bit  mode;  and  3)  using  the 
parallel  concepts  developed  in  the  signal  processing  programs  previously 
written  as  well  as  those  planned  for  future  development. 

3.6  ILLIAC  IV  Education 


3.6.1  Educati 


on 


3.6.1.1  ILLIAC  IV  Text 

The  initial  version  of  the  ILLIAC  IV  textbook  to  be  titled  "An 
Introductory  Description  of  the  ILLIAC  IV  System"  will  be  issued  next 
quarter.   Updated  material  will  be  sent  to  the  FOURUM  members  who  request 
copies  of  the  book.   Thus  the  distribution  will  be  handled  like  that  for 
the  "Systems  Characteristics  and  Programming  Manual." 
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.  1.1.2  ILLIAC  IV  Semin;n-. 

Following  is  the  outline  of  a  two-day  seminar  on  ILLIAC  IV  that 
was  held  on  August  2Uth  and  25th.  Two  more  of  these  seminars  are  planned 
for  next  quarter. 

August  2U,  19 TO 

Background  1  Hour  9:00  -  10:00 

Functional  Components  of  a  Computer 

Buffer  Concept  —  IBM  7090 ,  Overlap  of  Operations,  Example 

Pipeline  Concept  —  Pipelined  Adder,  Pipelined  Instruction 

Execution,  IBM  STRETCH 

Array  Processor  —  SOLOMON 

Multiprocessors  —  Multiprogramming  and  Multiprocessing, 

General  Multiprocessor,  Intrinsic 
Multiproces  sor 

ILLIAC  IV 

u      *  q+        +  c  v  10:0°   "   12:00 

Hardware  Structure  5  Hours  p-nn 

ILLIAC   IV  Array  —   General  Description,   Two   Illustrative 

Problems,   Data  Allocation  Considerations, 
A  More  Refined  Description 

ILLIAC   IV  Input /Output    (1/0)    System  —   1/0   Subsystem,   Disk 

File  System,   B65OO  Control   Computer, 
Datacommunications   Processor 

Test/Repair  Equipment   and  Diagnostics 

August   25,    1970 

o  *h-  e:  ti  9:00  -  12:00 

Software  5  Hours  2.00  _  hmQQ 

Programming  Languages  —  ASK,  GLYPNIR ,  FORTRAN 

Operating  System 

Utilities 

Capabilities   and  Applications      1  Hour  l+:00   -      5:00 
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3.6.1.3  CS-U91-B 

The  graduate  course  "Architecture,  Applications,  and  Languages 
for  a  Parallel  Computer"  (Computer  Science  U9I-B)  is  being  offered  again 
this  fall.   The  outline  follows: 

I.   Background  8  classes 

A.  Functional  Components  of  a  Computer 

B.  Buffer  Concept 

1.  Overlap  of  Operations 

2 .  Example 

C .  Pipeline  Concept 

1.  Pipelined  Adder 

2.  Pipelined  Instruction  Execution 

D.  Array  Processor 

1 .   SOLOMON 

E.  Multiprocessors 

1.  Multiprogramming  and  Multiprocessing 

2.  General  Multiprocessor 

3.  Intrinsic  Multiprocessor 

F.  ILLIAC  IV 

II.   Hardware  Structure  ik   classes 

A.   ILLIAC  IV  Array 

1.  General  Description 

2.  Two  Illustrative  Problems 

a.  Summing  an  Array  of  Numbers 

b.  Relaxation  Solution  to  Laplace's  Equation 

in  Two  Dimensions 

3.  Data  Allocation  Considerations 
h.      A  More  Refined  Description 

a.  Processing  Element 

b.  Processing  Unit 

i.   Processing  Element  Memory  (PEM) 
ii .   Memory  Logic  Unit  (MLU) 

c.  Control  Unit 

i.   Advanced  Station  (ADVAST) 
ii.   Final  Station  (FINST) 

(a)  Final  Queue  (FINQ) 

(1)  Final  Data  Queue  (FDQ) 

(2)  Final  Instruction 

Queue  (FIQ) 
iii.   Memory  Service  Unit  (MSU) 
iv.   Test  and  Maintenance  Unit  (TMU) 
v.   Instruction  Look  Ahead  (ILA) 
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B.  ILLIAC  IV  Input /Output  (I/O)  System 

1.  I/O  Subsystem 

a.  Control  Descriptor  Controller  (CDC) 

b.  Input /Output  Switch  (IOS) 

c.  Buffer  Input /Output  Memory  (BIOM) 

2.  Disk  File  System 

3.  B6500  Control  Computer 

a.  CPU 

b .  Memory 

c.  Multiplexor 

d.  Peripherals 

h.      Datacommunications  Processor 

a.  Remote  Terminals 

b.  Interactive  Graphics 

c.  Microfilm  Printer 

d.  Laser  Memory 

e.  ARPA  Network 

C.  Test/Repair  Equipment  and  Diagnostics 

1.  Processing  Element  Exerciser  (PEX) 

2.  Processing  Element  Memory  Exerciser  (PEMX) 

3.  Control  Unit  Card  Tester  (CUCT) 
k.      Diagnostics 

III.   Software  15  classes 

A.  Operating  System 

1.  General  Philosophy 

2.  ILLIAC  IV  from  the  Users  Point  of  View 

3.  Details  of  Operating  System 

a.  Burroughs  B65OO  MCP 

b.  Job  Parser 

c.  The  Creeper 

d.  Disk  Management 

e.  Collector  and  Loader 

f.  Job  Partner 

g.  Operating  System  IV 

h.   Data  Processor  on  Other  Modules 
h.      Implementation  of  the  Operating  System 

B.  Programming  Languages 

1.  General  Philosophy  and  a  Brief  History 

2.  The  Assembler  System 

a.  Assembler 

b .  Macro  Generator 

c.  Simulator 

3.  Intermediate  Languages 

a.  GLYPNIR 

b .  FORTRAN 

h.      Higher  Level  Languages 

a.  Experience  with  TRANQUIL 

b.  APL 

5.   Implementation  Techniques 
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C.   Utilities 

1.  Data  Communications  Software 

2.  Program  Debugging  Software 

3.  Statistical  Package 

h.      Linear  Programming  Package 

IV.   Capabilities  and  Applications  3  classes 

3.6.2  Documentation 

3.6.2.1  Quarterly  Progress  Report 

The  distribution  list  of  the  ILLIAC  IV  QPR  has  been  effectively- 
decreased  by  approximately  200  people  as  the  result  of  a  "weeding"  letter 
to  QPR  recipients . 

3.6.2.2  FOURUM 

Requests  for  research  documents  have  been  steadily  received 
from  FOURUM  subscribers  since  the  publication  of  the  July  issue  of  FOURUM. 

One  hundred  documents  per  month  have  been  requested  by  FOURUM 
members  (outside  the  University  of  Illinois). 
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4.   ADMINISTRATION 

4.1  Administration  and  Services 

4.1.1  Financial  Report 

Actual  expenditures  and  commitments  for  July  and  August,  1970 

July  August 

Burroughs   Corporation  $714,784.00  $1+31,000.00 

University   of  Illinois  210,074.86  198,097-02 

Expenditures    and  commitments   to  date — through  August,    1970: 

Burroughs  $23,766,784.00 

University  5,659,542.92 

Budgeted  expenditures — First   Quarter,   Fiscal  Year  1971: 

July August  September 

Burroughs  $21+4,630.00  $239,078.00  $167,502.00 

University  195,398.00  195,398.00  195,398.00 

4.1.2  Personnel  Report 

Project  personnel  strength: 

Professional  1+2  1/4 

Non-Academic  18 

Research  Assistants  26 

Hourlies  24 

IHini  Girls  (Secretarial 

Assistants)  7 


117  1/4 


The  ILLIAC  IV  Project  Business  Office  nov  has  an  accounting 
clerk  who  assists  in  financial  matters  and  related  record  keeping. 
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U.1.3  Contract  Status 

Amendment  V  to  the  Burroughs  sub-contract  is  pending  approval, 

The  building  designed  to  house  the  Center  for  Advanced  Compu- 
tation is  within  approximately  thirty  days  of  the  originally  scheduled 
occupancy  date  of  January,  1971. 
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